Summary and collection to make everyday git works easier.
git diff --name-only HEAD^will show:
\n git diff --name-only OLD_COMMIT_ID NEW_COMMIT_ID git cherry -v developmentwill show all commits different btw current-branch and development-branch
\n git checkout --orphan NEW_BRANCH_NAME_HERE git checkout development -- src/environment/dashboard/campaign/monitor/agents/agents.jsIf you are working in a team and all of them are working on same branch, probably you use fetch/merge quite often. this sometimes resets your environment specific config files which you have to change every time after merge. Using this command, you can ask git to ignore the changes to specific file. So next time you do merge, this file won’t be changed on your system.
git update-index —assume-unchanged src/params.rc.dist
\nThe name-rev command can tell you the position of a committ with respect to a last release. Using this you can check if your changes were part of the release or not.
git name-rev --name-only COMMIT_HASH_HERE If you are working in a team which is working on same branch, then you have to do fetch/merge or pull quite often. Branch merges in git are recorded with merge commit to indicate when a feature branch was merged with mainstream. But in the scenario of multiple team members working on same branch, the regular merge causes multiple merge messages in the log causing confusion. So you can use rebase with pull to keep the history clear of useless merge messages.
git pull --rebase git checkout --theirs development src/.../monitor.js git log --follow -p -- package.json\ngit log --follow --all -p package.json\n\n\ngit log --follow -p -- package.json\ngit log --follow --all -p package.json\ngit log --pretty=short -u -L package.json\ngit log -p\n\ngit add -p [file_name]\ngit rebase -i HEAD~[number_of_commits]\ngitk --follow --all -p package.json\ngit branch -vvFor git branch -vv:\n-v, -vv, —verbose\nWhen in list mode, show sha1 and commit subject line for each head, along with\nrelationship to upstream branch (if any). If given twice, print the name of the\nupstream branch, as well (see also git remote show
It’s the natural instinct of human beings to blame others when something goes wrong. If your production server is broke, it’s very easy to find out the culprit — just do a git blame. This command shows you the author of every line in a file, the commit that saw the last change in that line, and the timestamp of the commit.
\ngit blame [file_name]\n\ngit stash\ngit stash list\ngit stash apply\ngit stash pop\ngit stash clear\n\ngit diff --stat\ngit log --statLog actual changes in a file
\ngit log -p filenameExtract a file from another branch
\ngit show some-branch:some-file.jsSample git diff -w or git blame -w
\nPick a commit from another branch\nIt’s sometimes useful to pick a commit from another branch to add it in the current branch.
\ngit cherry-pick [commit_hash]
\nMost Git commands expect some kind of revision. Usually you pass in a branch name or a SHA1 of a specific commit, but Git revisions are much more powerful than that.
\nFirst, there is a special revision called head (also known as HEAD). head is whatever point your working directory currently is at, usually the tip of a branch.
\nSecond, you can easily reach older commits given a starting ref without having to know their SHA1. Let’s say you want to specify the commit that came before the current one (also called “parent”): Simply type head^. The great-grandfather? head^^^. However, the farther back you go in history, the more cumbersome it gets. So Git also offers an alternate syntax for this: The great-grandfather can also be specified using head~3.
\nWant to reach the commit whose commit message matches a certain string? Use :/really awesome commit to find that really awesome commit.
\nbranch@{yesterday} will give you the revision that branch was at yesterday, branch@{2 days 3 hours 4 seconds ago} is the branch, well, 2 days, 3 hours and 4 seconds ago.
\nI’ve only scratched the surface of what’s possible, so make sure you read the man page.
\n